fix: bound the number of entries in a compression table advertisement (#3510) - #3521
Merged
Conversation
…apache#3510) Motivation: deserializeCompressionAdvertisement resolves every key in the advertised table, and for actor refs that means parsing a path and populating the resolve cache. The key list was unbounded, so the only limit was the transport frame size. Measured, 10000 entries is 369 KB of wire and about 150 ms of CPU on the inbound control stream, against 9 KB for the 256 entry table a peer legitimately advertises. Modification: Reject an advertisement carrying more entries than pekko.remote.artery.advanced.compression.<table>.max, the setting that bounds the table on the sending side and is normally the same across a cluster. When it is "off" locally there is no number to check against and no bound is applied. Result: An oversized advertisement is reported as a serialization failure, which the inbound stream logs and drops. Advertisements are resent periodically, so a dropped one costs at most a delay in establishing compression.
pjfanning
requested review from
He-Pin,
Philippus,
nvollmar,
raboof and
samueleresca
September 4, 2026 12:56
nvollmar
approved these changes
Sep 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Backport of #3510 to 1.7.x: a compression table advertisement carried an unbounded number
of entries, each of which is resolved on the inbound control stream — for actor refs that
means parsing a path and populating the resolve cache — bounded only by the frame size.
Modification
Cherry-pick of 6751ab9. Conflicts were confined to import blocks in
ArteryMessageSerializer(1.7.x also importsFlush/FlushAckthere) and its spec(adding
ArteryControlFormatsto an existing import); the change itself applied clean.Result
Same as #3510: an advertisement carrying more entries than the receiver's configured
pekko.remote.artery.advanced.compression.<table>.maxis rejected as a serializationfailure; a legitimately sized one is unaffected, and no bound is applied when compression
is off locally.
Tests
sbt "++ 2.12.21 remote/Test/compile"— clean, validating Scala 2.12formatting drift in
NestedPayloadDepthSpecon 1.7.x, left untouched)fix: bound the number of entries in a compression table advertisement #3510 (exactly
maxaccepted,max + 1rejected) is includedReferences
Backport of #3510.